In distributed computer systems such as multiprocessor computer platforms, time stamps are employed to resolve the order of system events by providing a unique code that identifies each system event. In general, a time stamp is generated by an event trigger to provide an absolute or relative identification of the time at which the event occurred. The time stamp for a sequence of events on a system may be chosen to indicate the time before a sequence of events, the time immediately before a specific event, the time immediately after a specific event, or the time after all events have occurred. Regardless of the process of time stamping selected, the synchronization of time stamps is important. Unsynchronized or out-of-order time stamps may cause events to be executed in the wrong order leading to data corruption or a system crash.
In a multiprocessor system, time stamps may be generated from different sources, e.g., from different processors. Typically, each time stamp is issued by the processor handling the event and the processor's associated interval timer. In order to coordinate the time stamps between processors, the processors are synchronized to correct any discrepancies between the interval timers. FIG. 1 depicts a multiprocessor computer platform 100 employing a prior art solution for synchronizing a monarch processor and a slave processor. A monarch processor 102 having an interval timer 104 is associated with the multiprocessor computer platform's hardware space. An interval timer synchronization structure 106 is located in the platform's kernel space which provides the parameters necessary for synchronizing interval timers of other processors to the interval timer 104.
Similar to monarch processor 102, slave processor 108 is disposed in the hardware space of the computer platform 100 and includes an interval timer 110 as a local timing reference. Slave processor 108 is associated with the interval timer synchronization structure 106 disposed in the kernel space. In one existing process, the monarch processor 102 synchronizes the slave processor 108 at periodic intervals depending on the desired performance overhead. The longer the interval between synchronization operations, the less the performance overhead, but the greater the chance of clock drift. When it is time to synchronize the slave processor 108, the monarch processor sends the slave processor 108 an interrupt 114 which specifies to the slave processor 108 a timing window rendezvous.
At the agreed upon timing window, the slave processor 108 sends a handshake 116 to the monarch processor 102. Upon receiving the handshake 116, the interval timer synchronization structure 106 of the monarch processor 102 provides the slave processor 108 with a time value 118 which is indicative of the time maintained by the interval timer 104. The interval timer synchronization structure 106 of slave processor 108 uses the time value 118 to update its synchronization data to compensate for any discrepancies between the monarch's interval timer 104 and the local interval timer 110. This synchronization processes may require additional overhead (e.g., OS cycles) if the monarch processor 102 and slave processor 108 have different clock speeds.
If the monarch processor and slave processor do not respond to each other at the agreed upon timing window, the synchronization fails. Since each processor runs many other routines, the timing window for the synchronization arbitration between the monarch processor and slave processor is generally short. The shorter the timing window, however, the greater the chance either the monarch processor or slave processor will have a conflict and will not be available.
As discussed, the conventional clock synchronization processes are limited by the frequency of synchronization and duration of the timing window. Additionally, the synchronization process may be encumbered by the number of slave processors. In a multiprocessor computer platform, the monarch processor must synchronize each slave processor. Hence, in a system of n slave processors, n synchronization rendezvous events must be coordinated. This can tax the platform to the point that the monarch processor spends a substantial amount of its resources synchronizing slave processors.